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METHOD FOR FORMING AN INTERFACE 

TECHNICAL FIELD 

The presented invention is concerned with 
telecommunications technology. The invention espe- # 
5 cially targets on a method for the forming of a termi- 
nal independent interface for security functions be- 
tween a service and its recipient while using stan- 
dardized page description language. 

10 BACKGROUND OF THE INVENTION 

The use of the wireless application protocol 
(WAP, Wireless Application Protocol), is becoming more 
common in solutions where a connection between mobile 
terminals, " as a mobile phone, and internet applica- 

15 tions, for instance e-mail, the WWW (World Wide Web) 
and newsgroups, is needed. The wireless application 
protocol offers an architecture which fits mobile 
phones, the browser programs of mobile phones and the 
WWW into a working wholeness. The HTML-language (Hyper 

20 Text Markup Language) used in the WWW can, when neces- 
sary, be transformed into WML (Wireless Markup Lan- 
guage) which has been developed for the wireless envi- 
ronment, when data is transferred to mobile stations. 
At present the description language of the WAP- 

25 standard is the WML-language, but also any other de- 
scription language in accordance with the coming WAP- 
standard can be comprised as the language. 

The wireless application protocol comprises 
five layers: the wireless application environment 

30 (WAE, Wireless Application Environment) , the wireless 
session layer (WSL, Wireless Session Layer) , the wire- 
less transaction layer (WTL, Wireless Transaction 
Layer) , the wireless transport layer security layer 
(WTLS, Wireless Transport Layer Security) and the 

35 wireless transfer layer (WDP, Wireless Datagram 
Layer) . With wireless application environment it is 
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meant for instance WTA (WTA, Wireless Telephone Appli- 
cation) or any other suitable environment. There is 
furthermore a system dependant layer as the lowest 
layers , which defines the way in which the informa- 
5 tion is transported inside the system in question. At 
present • the last accepted WAP-specif ication version 
number is 1.3. 

The especial purpose of the WAP-architecture 
is to make it possible to use, among others, services 

10 in the internet on the mobile terminals, the data han- 
dling ability, screen size or memory capacity of which 
is small or limited. Terminals like the ones described 
are for instance mobile stations and PDAs (PDA, Per- 
sonal Digital Assistant) . The WAP-specif ication does 

15 not take a stand on how the air interface is realized. 
This makes it possible for several different opera- 
tors, terminal manufacturers and program manufacturers 
to benefit from the possibilities that the standard 
brings with it. 

20 At present the problem is how to use the 

standardized page description language, for instance 
WML, for the making of an encryption and a digital 
signature without restricting to .a certain encryption 
or signature method or terminal. Furthermore, a prob- 

25 lem is that for instance the WTLS -encrypt ion handling 
the encryption of data in the WAP-protocol is not a 
pure end-to-end encryption; the encryption can be de- 
crypted in between. The contents can be accessed and 
thus the risk is that it can be altered. Thus, the 

30 confidence, in the data contents and its integrity is 
lost . 

A certain solution is to use" manufacturer 
specific page description languages, for example a 
manufacturer specific WML- language, which still is not 
35 in accordance with a standard. This leads to that all 
the components in the network and the terminal at the 
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end of the chain do not understand the manufacturer 
specific page description language. 

Another solution is to use script language, 
for example WMLScript, but the problem with this al- 
5 ternative is the lack of functions necessary for en- 
cryption and signature. Furthermore, the inconvenience 
with using the script -language is that the terminals 
browser program does not necessarily support the use 
of the script language. 

10 In addition, a situation where new. functions 

are wanted to be added to the service becomes trouble- 
some. The producer of the service has to translate the 
program after each change. The changes made are often 
dependent on the terminal, so different changes have 

15 to be made on different programs. 

OBJECT OF THE INVENTION 

The purpose of the invention is to remove or 
at least significantly alleviate the disadvantages 
20 mentioned above. Especially, the invention is con- ■ 
cerned with a new kind of method, with which a termi- 
nal-independent interface can be offered to the serv- 
ice provider, through which interface functions con- 
cerned with the security measures can be called. 

25 

SUMMARY OF THE INVENTION 

The present invention is concerned with a 
method for the forming of a terminal -independent in- 
terface for security functions between the service and 

30 the recipient while using a standardized page descrip- 
tion language. With standardized page description lan- 
guage it is .referred to for example the WML- language. 

In the method in accordance with the inven- 
tion the function call requests concerned with the se- 

35 curity measures are encapsulated in the service into a 
document in accordance with the standardized page de- 
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scription language. If the page description language 
is WML, the do-element with a type-attribute is used, 
with which do-type the security measures to be per- 
formed to the proxy-server are defined. 
5 With service it is referred to a service of- 

fered by a service provider, where security measures 
are needed. Security measures are for instance a digi- 
tal signature, the verification of a digital signa- 
ture, the encryption of data, the decryption of data 

10 and so forth. A service provider is for instance a 
bank, a credit card company, an Internet shop etc. A 
service is therefore for instance a bank service that 
demands security measures. The service adds the iden- 
tity data referring to the final recipient of the 

15 document into the document formed by the service. The 
service transmits the document to the proxy-server. 
Said functions are called with the proxy- server for 
the realisation of said security measures. The func- 
tion calls can be realized on the proxy-server itself 

20 or they can be transmitted to a separate PKI- server, 
which takes care of the security measures. In said se- 
curity measures a symmetric or an asymmetric method is 
used for the signature and/or encryption. Methods like 
these are for instance 3DES (3DES, Triple Data Encryp- 

25 tion Standard) and RSA (RSA, Rivest Shamir Adleman) . 

The protocol used by the recipient is checked 
with the proxy-server. The document in accordance with 
the standardized page description language handled 
with the security measures received from the service 

30 is transmitted with the proxy- server to the recipient 
with the transmission protocol understood by the re- 
cipient. If the page description language is WML, the 
document in accordance with the standardized WML- 
language is, if necessary, changed to a manufacturer 

35 specific WML-language, XML-language (XML, extended 
Markup Language) or to another form understood by the 
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recipient. If the recipient cannot interpret the re- 
ceived document, it can be ignored. 

The sending of information between the serv- 
ice and the recipient can be activated in different 
5 ways. In a certain case the recipient first sends a 
request, to which the service responds. In another 
case the service sends information to the recipient 
with a push-method without a request from the recipi- 
ent. In the before mentioned case the proxy-server 

10 checks the protocol used by the recipient in the re- 
quest and transmits the document, received from the 
service as a response to the request, in accordance 
with the standardized page description language which 
has been handled with security measures to the recipi- 

15 ent in accordance with the protocol used by the re- 
cipient. 

In the latter case the recipient does not 
first transmit a service request to the service, but 
the service uses the push- function. In this case the 

20 service sends the document to be sent to the recipient . 
to the proxy- server and at the same time identifies 
the recipient, to which the proxy-server later, trans- 
mits the document handled with the security measures. 
The identification data is for instance a network 

25 identity or an MSISDN-number (MSISDN, Mobile Sub- 
scriber ISDN) . A network identity is an unambiguous 
user specific identifier, to which signature and en- 
cryption keys have been attached during the creation 
of it . Corresponding data pairs are maintained on the 

30 proxy-server, with which the recipient's identifica- 
tion data and transmission protocol are tied together. 
The proxy- server can choose the right transmission 
protocol on the basis of the identification data con- 
nected with the recipient received from the service. 

35 Because of the present invention the faction 

offering services to a fixed line or wireless terminal 
which demand security measures does not need to care 
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about the recipient's terminal or its attributes. An 
interface is offered to the faction offering a serv- 
ice, through which it calls the necessary security 
measures in a terminal independent way. The security 
5 function requests are always sent from the service in 
accordance with the standardized page description lan- 
guage. Because of the interface the faction offering 
services does not need to update its software with 
terminal specific changes. 
10 Because of the invention the functions con- 

cerned with the digital signature and encryption can 
be taken into widespread use regardless of page de- 
scription language. 

15 BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are included 
to provide a further understanding of the invention 
and constitute a part of this specification, illus- 
trate embodiments of the invention and together with 
20 the description help to explain the principles of the 
invention. In the drawings: 

figure 1 presents the functioning of the 
method in accordance with the presented invention, and 

figure 2 presents a certain advantageous sys- 
25 tern, in which the method in accordance with the inven- 
tion can be realized. 



DETAILED DESCRIPTION OF THE INVENTION 

Figure 1 presents the functionality of the 
30 method in accordance with the invention. The method in 
accordance with the invention is concerned with the 
forming of a terminal independent interface for the 
security measures between the service and the recipi- 
ent while using standardized page description lan- 
35 guage. Security measures are for instance a digital 
signature, the verification of a signature, the en- 
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cryption of data, the decryption of data etc. With 
standardized page description language it is referred 
to for instance WML-language . 

In accordance with block 10 the necessary 
5 function requests concerned with the security measures 
are encapsulated into the document in accordance with 
the standardized page description language. The serv- 
ice can send information to the recipient with the 
push-method without an actual service request . In the 

10 second alternative the recipient has, before block 10, 
sent a service request for the receiving of informa- 
tion. In this case the service request made by the re- 
cipient contains the identification data of the re- 
cipient, on the basis of which the service can send 

15 the response to the right recipient. 

The service attaches the identification data 
of the recipient into the document, block 11. In ac- 
cordance with block 12 . the document is transmitted to 
the proxy-server. With the proxy-server said functions 

20 are called for the realisation of said security meas- 
ures, block 13. Said functions can be called in the 
proxy- server or in a separate PKI- server (PKI, Public 
Key Infrastructure) . A symmetric or an asymmetric 
method is used for the signature and/or encryption 

25 concerned with the security measures. 

In accordance with block 14 the protocol used 
by the recipient is checked with the proxy- server . The 
proxy-server maintains corresponding data pairs, with 
which the identification data and transmission proto- 

30 col of the recipient are tied together. With the iden- 
tification data it is for instance referred to a net- 
work identity or an MSISDN-number . The network iden- 
tity is an unambiguous user specific identity, to 
which has been attached signature and encryption keys 

35 during its creation. The proxy-server searches identi- 
fication data of the recipient defined by the service 
and can thereby choose the right transmission proto- 
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col. The proxy-server transmits the document, in ac- 
cordance with the page description language, handled 
with the security measures to the recipient using the 
transmission protocol understood by the recipient, 
5 block 15, If the recipient cannot interpret the re- 
ceived document, it can be ignored. 

Because of the invention the security func- 
tion requests are always sent using the standardized 
page description language. Because of the interface 

10 the faction offering services does not need to update 
its software with terminal specific changes. 

The example in accordance with figure 2 con- 
sists of the service BE, the proxy- server SC, the PKI- 
server PKI and the recipient WIB. With service BE it 

15 is referred to for instance a bank's, a credit insti- 
tution's or an online trader's service in which secu- 
rity measures are taken advantage of. Security meas- 
ures are for instance a digital signature, the verifi- 
cation of a signature, the encryption of data, the de- 

20 cryption of data etc. The proxy-server can execute the 
demanded security functions itself or send the func- 
tion requests concerned with the security measures to 
the PKI -server PKI. 

In the example in accordance with figure 2 

25 information between the service BE and the proxy- 
server SC is transmitted in accordance with the stan- 
dardized WML-description language. The information be- 
tween the proxy-server SC and the recipient WIB is 
transmitted in accordance with WML- language, manufac- 

30 turer specific WML-language, XML-language or in accor- 
dance with another form of data transfer suited to the 
purpose. With recipient the WIB it is advantageously 
referred to a terminal, a browser program of a termi- 
nal, software of a terminal or other, with which the 

35 information sent from the proxy- server SC can be han- 
dled. 
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9 

In the following the functioning of the exam- 
ple in accordance with figure 2 is explained more spe- 
cifically. Even though it is presented in the follow- 
ing that the page description language between the 
5 service and the proxy-server is WML, it can be any 
other language suited for the purpose, for example 
XML, HTML (Hyper Text Markup Language) , HDML (HDML, 
Handheld device Markup Language) etc. The starting 
point of the invention is to function in such a way 

10 that the data traffic between the service BE and the 
proxy-server SC is in accordance with standardized 
page description language. 

In this example the do-element is used with 
the type-attribute. The type -attribute gives the re- 

15 ceiving party a reference on how the user of the do- 
element wants it to be used; Most of the type- 
attributes are reserved, but experimental and manufac- 
turer specific ones have been defined into the lan- 
guage. These attributes can be used to broaden the 

2 0 WML- language, but still simultaneously preserve the 
definitions of the WML- specif icat ions. When manufac- 
turer specific type-attributes are used, the proxy- 
server SC can interpret the requests concerned with 
the security measures from a standard according WML- 

25 document, whereas standardized WAP-clients ignore this 
information. 

The interface and the way in which the serv- 
ice BE sends security function requests to the proxy- 
server is described in the following. A signature re- 

30 quest has been presented in the following. 

<do type=" vnd. smarttrust . sign" label=" SIGN" optional^ 
"true"> 

<ref resh> 

35 <setvar name=" signParam" value=" foo" /> 

<setvarname= /, transID' , value= ,, TRANSACTION ID"/> 
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<setvar name=" options" value=" OPTIONS" /> 
<setvar name^' keyldType" value=" 1234 5" /> 
<setvar name=" keyld" value="KEY_ID" /> 
<setvar name="userIDType" value=" 1234 5" /> 
5 <setvar name="userID" value="USERID" /> 

<setvar name=" modifiable" value=" true | false" /> 
</ref resh> 
</do> 

10 The label-attribute in the do-element has at 

most a length of six characters and it only serves a 
purpose as a giver of information. The optional - 
attribute in the do-element makes it possible for the 
recipient WIB to ignore the used do-element. 

15 Of the columns appearing in the table WIG re- 

fers to the realisation way of the invention and WAP 
to the realisation way- of the nearest technical stan- 
dard. In the columns " n M" " means mandatory and "O" op- 
tional . 

20 



Attribute 


Type 


Explanation 


WIG 


WAP 


UserlD- 
Type 


String . 
(Inte- 
ger 
Value) 


Defines the user iden- 
tification type which 
the service BE uses, 
with which it is placed 
abreast with the 
NID/MSISDN used by the 
proxy-server SC. 
NID = 1 
MSISDN = 2 
BESPECIFIC = 3 


M 


M 


UserlD 


String 


Identifies the user. 


M 


M 


Sign 
Pa ram 


String 


The name of the URL- 
parameter which is re- 
turned in the HTTP GET- 


M 


M 



WO 02/41602 



PCT/FI01/00985 



11 







request, signed by the 
recipient WIB. 






TransID 


String 


An unambiguous transac- 
tion mark. 


M 


M 


Options 


Integer 


In use only in WAP- 
client programs. 


0 


M 


KeylD 
Type 


String 
(Inte- 
ger 
Value) 


In use only in WAP- 
client programs 


0 


M 


Key ID 


String 


In use only in WAP- 
client programs. 


0 


M 


Modifi- 
able 


String 


Defines if the signed 
parameter is static 
("false") or dynamic 
("true") . 


0 


0 



The interface and the way in which the serv- 
ice BE sends security function requests to the proxy- 
server is described in the following. Another way to 
5 make a signature request is presented in the follow- 
ing. The MAC (ISO 9797) method is used. On the basis 
of the request the fed information is signed with the 
3DES-method (3DES, Triple Data Encryption Standard) in 
an external CBC-mode (CBC, Cell Block Cipher) using 
10 two keys. 

<do type="vnd.smarttrust. kmac" label="KMAC" optional= 
"true"> 

<ref resh> 

15 <setv'ar name=" signParara" value=" too" /> 

<setvar name=" transID" value="TRANSACTION_ID" /> 
<setvar name="userIDType" value=" 12345" /> 
<setvar name="userID" value=" USERID" /> 
<setvar name=" modifiable" value=" true | false" /> 
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12 

</ref resh> 
</do> 

The label -attribute in the do- element has at 
5 most a length of six characters and it only serves a 
purpose as a giver of information. The optional - 
attribute in the do-element makes it possible for the 
recipient WIB to ignore the used do-element. 



Attrib- 
ute 


Type 


Explanation 


WIG 


WAP 


UserlD- 
Type 


String 
(Inte- 
ger 
Value) 


Defines the user iden- 
tification type which 
the service BE uses, \ 
with which it is placed 
abreast with the 
NID/MSISDN used by the 
proxy-server SC. 
NID = 1 - 
MSISDN = 2 
BESPECIFIC = 3 


M 


M 


UserlD 


String 


Identifies the user. 


M 


M 


Sign 
Param 


String 


The name of the URL- 
parameter which is re- 
turned in the HTTP GET- 
request, signed by the 
recipient WIB. 


M 


M 


TransID 


String 


An unambiguous transac- 
tion mark. 


M 


M 


Modifi- 
able 


String 


Defines if the signed 
parameter is static 
("false") or dynamic 
("true") . 


0 


0 . 
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The interface and the way in which the serv- 
ice BE sends security function requests to the proxy- 
server is described in the following. An encryption 
request is presented in the following. On the basis of 
5 the request the input information is encrypted using 
the 3DES -method in an external CBC-mode using two 
keys. 

<do type="vnd.smartt rust. encrypt" label=" ENCR" op- 
10 tional="true"> 
<refresh> 

<setvar name=" encrypt Param" value=" foo" /> 
<setvar name="userIDType" valued' 12345" /> 
<setvar name="userID" valued USERID" /> 
15 </refresh> 
</do> 

The "X 11 in the table means that the nearest 
technical standard WAP does not at present support 
20 this function. 



Attrib- 
ute 


Type 


Explanation 


WIG 


WAP 


Encrypt 
Param 


String 


Character line which 
contains the name of 
the variable which the 
recipient WIB encrypts. 


M 


X 


UserlD- 
Type 


String 
(Inte- 
ger 
Value) 


Defines the user iden- 
tification type which 
the service BE uses, 
with which it is placed 
abreast with the 
NID/MSISDN used by the 
proxy-server SC. 
NID = 1 


M 


X 
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MSISDN = 2 
BESPECIFIC = 3 






UserlD 


String 


Identifies the user. 


M 


X 



The interface and the way which the service 
BE sends security function requests to the proxy- 
server is described in the following. A decryption re- 
5 quest is presented in the following. On the basis of 
the request the encryption is decrypted with the 3DES- 
method in an external CBC-mode using two keys. 

<do type=" vnd . smarttrust . decrypt" label=" DECR" op- 
10 tional="true"> 
<refresh> 

<setvar name="stringToDecrypt" value=" plain" /> 
<setvar name=" decryptedString" value=" f oo" /> 
<setvar name="userIDType" value=" 12345" /> 
15 <setvar name="userID" value=" USERID" /> 

</refresh> 
</do> 
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Attribute 


Type 


Explanation 


WIG 


WAP 


StringTo 
-Decrypt 


String 


Information which is en- 
crypted using the proxy- 
server and which the re- 
cinient WIB decrvots 


M 


X 


De- 
crypted 
String 


String 


A variable, to where the 
information which has 
been decrypted by the 
recipient WIB to plain 
text is set. 


M 


X 


UserlD- 
Type 


String 
(Inte- 
ger 
Value) 


Defines the user identi- 
fication type which the 
service BE uses, with 
which it is placed 

flhros mi f ho 

CLXJ A. t3 CI O L. WJLL.il LUC 

NID/MSISDN used by the 
proxy-server SC. 
NID = 1 
MSISDN = 2 
BESPECIFIC = 3 


M 


X 


UserlD 


String 


Identifies the user 


M 


X 



Furthermore, the interface between the serv- 
ice BE and the proxy-server SC is described in the 
following. When implementing security measures it is 
5 possible to take advantage of the first function 
call's output as the argument for the second function 
call. Such a situation can arise in for instance the 
following situations. 

1. The service BE sends information, which is 
10 encrypted using the proxy-server SC and 

which the recipient WIB decrypts. The value 
of the decrypted variable can furthermore 
be for instance shown to the user or be 
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used as an argument for an encryption serv- 
ice. 

2. The information is signed before performing 
the encryption. 
5 In the following it is exemplary presented, 

how the data in the contract-variable is signed using 
the do-type and then how the signed data in the con- 
tract-variable is encrypted using the do-type (con- 
tract consists of all the variables prefix, amount and 
10 suffix) . 

<do type=" vnd. smartt rust . sign' 7 optional=" true" > 
<ref resh> 

<setvar name=" modifiable" value=" true" /> 
<setvar name=" signedParam" value=" contract" /> 
<setvar name="userIDType" value="3"/> 
<setvar name="userID" value-" test user"/> 
</refresh> 
</do> 

<do type=" vnd . smarttrust . encrypt" optional=" true" > 
<r.ef resh> 

<setvar name=" encrypt Par am" valued contract" /> 
<setvar name="userIDType" value="3"/> 
<setvar name="userID" valued test user // /> 
</ref resh> 
</do> 

<P> 

30 <anchor> 
<go 

href="http://www-backend.com/file?contract=$ (prefix) $ ( 
amount) $ (suffix) "/> 
</anchor> 
35 </p> 



15 



20 



25 
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In the following it is exemplary presented, 
how the proxy- server SC can alter the presentation 
form of the generic do-type in order to correspond to 
the receiving terminal while using security functions. 
5 The recipient WIB requests sensitive informa- 

tion from the service BE. The service BE transmits the 
following WML- card as a response to the request to the 
proxy- server SC. 



10 <wml> 

<card> 

<do type=" vnd . smarttrust . decrypt" optional=" true" > 
<refresh> 

<setvar name=" stringToDecrypt" value="account 
15 balance : -100 FIM"/> 

<setvar name="decryptedString" value=" output" /> 
<setvar name=" userlDType" value=" 3" /> 
<setvar name="userID" value="test user"/> 
</refresh> 
20 </do> 
<p> 

$ (output) <! — displays the data without padding 
bytes — > 
</p> 
25 </card> 
</wml> 

The proxy- server SC encrypts the character 
line "account balance: -100FIM" and transmits the in- 

30 formation to the recipient WIB. The recipient WIB de- 
crypts the encryption and stores the data into .the 
output-variable, which value can be for instance shown 
to the user. 

It is described as an example in the follow- 

35 ing, how the recipient WIB sends confidential informa- 
tion to the service BE. The data to be sent is for in- 
stance a password. The user enters the password to a 
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given input field. The recipient WIB encrypts the 
value of the pwd-variable (password) and sends it to 
the proxy- server SC. 

5 <wml> 

<card> 
<P> 

<input titled enter password" type=" text" 
name=" pas sword" /> 
10 </p> 

<do type="vnd. smarttrust . encrypt" opt ional=" true" > 
<ref resh> 

<setvar name-' encrypt Par am" . value="pwd" /> 
<setvar name=" userlDType" value=" 3" /> 
15 <setvar name-' user ID" valued test user // /> 

</ref resh> 
</do> 
<p> 

<anchor> 

20 <go href="http: //www. back-end. com/f ile?pwd=$ (pas 

sword) "/> 

</anchor> 
</p> 
</card> 
25 </wml> 

The proxy- server SC decrypts the encryption 
of the pwd-variable and sends an HTTP GET-request to 
the service, which consists of the stored plain text 
30 of' the pwd-variable. 

GET /file?pwd= "password entered" HTTP /l.l 

It is described as an example in the follow- 
35 ing, how the recipient WIB signs and encrypts the re- 
ceived payment request or contract received from the 
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service BE. The recipient WIB uses the MAC-method for 
the signature. The example consists of three phases: 

1 . Encrypted data is sent to the recipient 
WIB, that consists of a frame agreement: 

5 "prefix" and "suffix". These can be any 

static data, for instance prefilled fields. 

2. The "contract" -variable consists of the 
following data; "prefix" + the input of the 
user + "suffix". The data said above is 

10 signed after the PIN- inquiry confirmation 

(PIN, Personal Identification Number) . 

3 . The data in the "contract "-variable said 
above is encrypted. 

15 <wml> 

<card> 

<do type="vnd.smarttrust. decrypt" opt ional=" true" > 
<refresh> 

<setvar name=" stringToDecrypt" value="I wish to 

20 buy"/> 

<setvar name="decryptedString" value="pref ix" /> 
<setvar name="userIDType" value=" 3" /> 
<setvar name="userID" value-' test user // /> 
</ref resh> 
25 </do> 

<do type=" vnd . smarttrust . decrypt" opt ional=" true" > 
<ref resh> 

<set var narae=" stringToDecrypt" value=" Pokemon 

30 Figures" /> 

<setvar name="decryptedString" value="suf f ix"/> 
<setvar name="userIDType" valued 3" /> 
<setvar name="userID" value="test user // /> 
</ref resh> 

35 </do> 



<P> 
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<input type="text" name=" amount" /> 
</p> 

<do type="vnd. smarttrust . kmac" optional^" true"> 
5 <refresh> 

<setvar name=" modifiable" valued true" /> 
<setvar name=" signedParam" value=" contract" /> 
<setvar name="userIDType" value="3"/> 
<setvar name="userID" valued test user"/> 
10 </refresh> 
</do> 

<do type="vnd. smarttrust • encrypt" optional=" true" > 
<refresh> 

15 <setvar name=" encrypt Par am" value=" contract" /> 

<setvar name="userIDType" value-' 3" /> 
<setvar name="userID" valued test user"/> 
</refresh> 
</do> 

20 

<P> 

<anchor> 

<go href="http:/ /www .back-end. com/f ile?contract=$ ( 
prefix) $ (amount) $ ( suffix) "/> 
25 </anchor> 
</p> 
</card> 
</wml> 

30 The proxy-server SC decrypts the encryption 

and verifies the signature. Thereafter the proxy- 
server sends an HTTP GET-request to the service BE. 

GET /f ile?contract=" I wish to buy X Pokemon fig- 
35 ures 11 &KMAC_FIELDS=" contract 11 HTTP /l.l 
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The request furthermore consists of the 
KMACMFIELDS-parameter, which indicates the verified 
parameters . 

It is described as an example in the follow- 
5 ing, how the recipient WIB signs and encrypts the pay- 
ment request or contract, received from the service 
BE. In this example the recipient WIB uses an RSA- 
signature. The example consists of three phases: 

1. Encrypted data is sent to the recipient 
10 WIB, that, consists of a frame agreement: 

"prefix" and "suffix". These can be any 
static data, for instance prefilled fields. 

2. The "contract" -variable . consists of the 
following data: "prefix" + the input of the 

15 user + "suffix". The data said above is 

signed after the PIN- inquiry confirmation 
(PIN, Personal Identification Number) . 

3. The data in the "contract "-variable said 
above is encrypted. 

20 

<wml> 
<card> 

<do type=" vnd . smarttrus t . decrypt" optional=" true" > 
<ref resh> 

25 <setvar name=" stringToDecrypt" value=" I wish 

to buy"/> 

<setvar name=" deer yptedStr ing" value="pref ix" /> 
<setvar name="userIDType" value="3"/> 
<setvar name="userID" value="test user"/> 
30 </refresh> 
</do> 

<do type=" vnd . smartt rust . decrypt" opt ional=" true" > 
<refresh> 

35 <setvar name=" stringToDecrypt" value=" Pokemon 

figures" /> 

<setvar name="decryptedString" valued suffix" /> 
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<setvar name="userIDType" valued 3" /> 
<setvar name^userlD 77 value="test user"/> 
</refresh> 
</do> 

5 

<P> 

<input type=" text 77 name==" amount 77 /> 
</p> 

10 <do type^vnd.smarttrust.sign 77 optional^ 7 true 77 > 

<refresh> 

<setvar name="modif iable" value="true 77 /> 
<setvar name=" signedParain 7 ' valued contract" /> 
<setvar name="userIDType" value=" 3 7 ' /> • 
15 <setvar name="userID" value="test user 77 /> 

</refresh> 
</do> 

<do . type=" vnd . smarttrust . encrypt 77 optional^ 7 true 77 > 
20 <ref resh> 

<setvar name="encryptParam 77 value= 77 contract 77 /> 
<setvar name= 77 userIDType 7/ value= 77 3 77 /> 
<setvar name="userID" value="test use.r"/> 
</refresh> 
25 </do> 

<P> 

<anchor> 

<go href =" http : / /www . back-end . com/f ile?contract==$ 
30 (prefix) $ (amount) $ (suffix) 77 /> 
</anchor> 

</p> 
</card> 
</wml> 

35 
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The proxy-server SC decrypts the encryption 
and verifies the signature. Thereafter the proxy- 
server sends an HTTP GET-request to the service BE. 

5 GET /f ile? contract - n I wish to buy X Pokemon fig- 
ures "&NR FIELDS=" contract" HTTP /l.l 



The request furthermore consists of the 
NRJFIELDS -parameter , which indicates the verified pa- 
10 rameters. 

In a certain application in accordance with 
figure 2 the <do type> -structure is not transmitted 
as such to the recipient. The <do type> -structure can 
be replaced with a manufacturer specific WMLScript 

15 plugin function call.. The function call referring to 
the signature is for instance of the form 
http: //manufacturer, com (sig, x, x) . If the recipi- 
ent's terminal is a computer the signature invitation 
in accordance with the <do type> -structure is changed 

20 for instance into the XML- signature request from. 

Because of the invention the functions con- 
cerned with the digital signature and encryption can 
be taken into widespread use regardless of page de- 
scription language used. With the present invention a 

25 service calls the necessary security measures in a 
terminal independent way through an interface offered 
to the service. The service does not need to care 
about the type of the terminal of the recipient. 

The invention is not limited to solely con- 

30 cern the application examples presented above, other 
variations are possible while staying within the . in- 
ventive idea defined by the claims. 
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1. A method for the forming of a terminal in- 
dependent interface for security functions between a 
service and a receiver using standardized page de- 

5 script ion language, 

characterized in that the method 
comprises the following steps: 

a) encapsulating in the service the necessary 
function call requests concerned with the security 

10 measures into a document in accordance with the stan- 
dardized page description language; 

b) including the identification data of the re- 
cipient into the document; 

c) transmitting the document to the proxy- server ; 
15 d) calling said functions with the proxy-server 

for the realisation of said security measures; and 

e) checking the protocol used by the recipient 
with the proxy- server; 

f ) transmitting the document in accordance with 
20 the standardized page description language handled 

with the security measures, received from the service, 
with the proxy-server to the recipient using a trans- 
mission protocol understood by the recipient. 

2. The method according to claim 1, c h a r a 
25 cterizedin that 

g) the received document is left unnoticed if the 
recipient cannot interpret the document. 

3. The method according to claim 1, c h a r a 
cterizedin that if the page description lan- 

30 guage is WML, then in step a) : 

using a do-element with a manufacturer specific 
type-attribute, with which the do-type defines the se- 
curity measures to be performed on the proxy- server . 

4. The method according to claim 1, c h a r a 
35 cterizedin that if the page description lan- 
guage is WML, then in connection with step f ) : 
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changing the document in accordance with the stan- 
dardized WML-language to a manufacturer specific WML- 
language, XML-language or to some other form under* 
stood by the recipient. 
5 5. The method according to claim 1, c h a r a 

cterizedin that in the signature and/or en- 
cryption, in said security measures, a symmetric or an 
asymmetric method is used. 

6. The method according to claim 1, c h a r a 
10 cterizedin that in step d) : 

calling said functions with the proxy- server from 
the PKI-server for the realisation of said security 
measures . 

7. The method according to claim 1, c h a r a 
15 cterizedin that before step a) : 

sending a service request from the recipient to 
the service. 

8. The method according to claim 7, c h a r a 
cterizedin that the service request comprises 

20 the identification data of the sender of the service 
request . 

9. The method according to claim 1, c h a r a 
cterizedin that corresponding data pairs are 
upheld on the proxy-server, with which the recipient's 

25 identification data and transmission protocol are tied 
together. 

10. The method according to claim 1 or 9, c 
haracterizedin that the recipient's iden- 
tification data is a network identity. 

30 11. The method according to claim 1 or 9, c 

haracterizedin that the recipient's iden- 
tification data is an MSISDN-number . 

12.' The method according to claim 1 or 9, c 
haracterizedin that in connection with step 

35 d) : 
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checking the transmission protocol used by the re- 
cipient with the proxy- server on the basis of the re- 
cipient's identification data. 



WO 02/41602 



PCT/FI01/00985 



1/2 




10 



the necessary function calls concerned with the 
security measures are encapseled into the docu- 
ment in accordance with standardized page desc- 
riotion laneuaee . 



11 -> 



the identification data of the recipient is included 
into the document : 



1 



12 the document is mediated to the proxy-server 



1 



L 
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said functions are called with the proxy-server 
for the realization of said security measures 



14 



the protocol used by the recipient is checked 1 
with the proxy-server I 



15 ^ 



the document handled with the security measures 
is mediated to the recipient with a transmission 
protocol understood by the recipient 
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